(Sun Microsystems, Inc.)(1997).iso/products/Cobb/ordlogo.gif)
By Carrie Anderson
Domains are a very powerful concept in the Designer/2000 product. However, the term domain often has a very precise meaning that differs within different methodologies. In this article, we'll explain how the Designer/2000 tool uses domains.
You can think of domains as an attribute/column template. You can assign to a domain property values that all attributes and columns that use the domain inherit. Be aware, however, that not all property values that you assign to a domain are passed on to attributes or columns.
In some circumstances you should always use a domain. For example, you should assign a domain to any attribute that is part of a primary unique identifier (and that will become a foreign key column in other tables). In addition, you should assign a domain to any attribute that appears in more than one entity, i.e., the date/time row created and the date/time row last modified.
There are some circumstances where domains might be useful. For example, your company wants to maintain a list of standard data elements. A domain might be useful for standardizing descriptions at a length of 80 characters and comments or notes at 1,500 characters. A domain might also be useful when you have attributes that have common allowable values. For example, you may have indicator attributes that are Boolean in nature, and you're implementing all of them as character fields of length 1, with allowable values Y and N.
Some application designers use domains with allowable values as an alternative to creating reference entities. For example, if you have an attribute representing traffic light colors, you might choose to place it within a domain that has allowable values of green, yellow, and red instead of creating a separate entity that contains the attribute color. We admit, the idea is appealing because you wouldn't have to program and test large numbers of reference screens and reference reports.
You've probably guessed that there must be more to it than this, or we wouldn't have written this article. You're right. Generating and testing 50 reference screens and 50 reference reports isn't as much work as you might think. If your reference tables contain relatively few columns, it doesn't take long at all to generate them. The work would be finished in under a week. However, you could easily avoid that week of work by using domains instead.
You should also consider the enforcement of relational integrity. If you implement each relationship as a foreign key to a reference table, then you can build a constraint to enforce it within the database. But if you use domains, you have two choices: Either use an all-purpose look-up table or use check constraints. Let's look at these options in detail.
Your first option is to insert the allowable values into an all-purpose look-up table. The values allowed in related columns aren't guaranteed by a relational database constraint. Generated forms will certainly correctly enforce that the column accepts only its domain's values, but other front-end tools might not. This might be a strong consideration if your system will be subjected to data maintenance from outside sources such as bulk data loading.
Your other option to enforce these values is to create a check constraint from the domain definition, using the Generate DDL option Valid Value Constraints. However, unlike a relational foreign key constraint to a dedicated look-up table, the check constraint would have to be dropped and rebuilt if the allowable values changed.
Here's the rule of thumb we use to decide whether to use a domain or a reference table:
Experience has revealed two important truths: First, while not as certain as Death and Taxes, never believe it when a user says the value will never change. Second, we never, ever, want to maintain anything. Guess which option we use in our own work.
The domain hierarchy is for documentation only. There is no concept of inheritance across domains in the Designer/2000 tool.
When you suddenly discover that a column that appears in 150 tables needs to be changed from a 10-character field to a 12-character field, you'll truly appreciate domains. Designer/2000 provides utilities you can use to update attribute and column characteristics to match the domain. Instead of updating all 150 columns individually, you can simply update the domain and run the utility. You can also find out which attributes and columns are using a domain from within the Repository Object Navigator. Under the File menu, select Open and turn the Show "Owned By" Associations only option off. Open the Application System and expand the domain in the Object Hierarchy window.
There's one quirky fact about domains: Some of their properties are immediately inherited by an attribute or column as soon as you specify that the item is part of the domain (for example, Maximum Length). Other domain properties are passed to the attribute or column only when you run the appropriate update utility (for example, Default). Don't let this bother you; just make a habit of running the utilities regularly. The Generators use other domain properties, including the allowable values, but they never actually appear on the attribute or column property sheets.
Another reason to use domains is that you can set user preferences at the domain level. This causes all columns within that domain to receive the same treatment by the Generators.
Each domain can have a valid range of values (such as 1 to 100), or you can define multiple, fixed allowable values for it (such as A, B, C). In Figure A we've created an additional properties window and pinned the right-hand properties window to the domain definition in the Repository Object Navigator. The properties window on the bottom left matches one of the three fixed allowable values (Y) for that domain. The following sections describe the properties you can define for domains.
This is the domain's true name. Where possible, we use the same name that the attributes using it would use. When attributes belong to a domain, the Database Design Wizard will assign the domain to all columns derived from those attributes. Please note: If you have trouble deciding on one name that fits all the attributes within the domain, then it probably should be more than one domain.
The Subset Of property refers to another domain. This property allows you to create a domain hierarchy, which is useful for documentation purposes but has no effect upon the Generators.
This domain property is used for documentation only. We usually enter the same text that we'd use for the attribute comment. (The attribute comment becomes the one-line column hint text.) Some domains use the same hint text regardless of the entity they appear in; others don't. For example, the domain "Created by User ID" will need the same hint line: "The User ID of the User who created this record." The domain "Country Code" might need a different hint line based upon its context, for example, "The Originating Country of Manufacture" or "The Country of Final Destination." We start all common comments with a tilde character (~) and use a custom utility to automatically update the related attributes and columns from this field.
These properties provide information for attributes within the domain. The fields are the same fields shown in the Entity Relationship Diagrammer when you open the Edit Entity window and select the Attribute Detail tab.
These properties provide information for columns within the domain. These are the same fields that are used by the Data Diagrammer in the Edit Table window when you select the Column Definition tab. The Database Design Wizard uses this information to create columns from attributes assigned to the domain.
The Authority property is for documentation only. You can ignore it.
The Default property is a fixed value that columns assigned to the domain would assume (unless overridden). The Database Design Wizard sets this property as the default for columns assigned to the domain.
You should ignore the Null Value property unless you're building your application for a non-Oracle database. It represents the character in the database that represents NULL.
The Soft LOV? property directs the Forms Generator to validate columns within the domain against a Designer/2000-created reference table, as opposed to hard-coding the values into the form. This type of validation is more easily maintained than hard-coded form values, thus the term Soft. Although this property is not copied to columns in the domain, like the domain's valid values it does affect the Generators' treatment of the column. If you intend columns within this domain to have soft validation, you must define the list of valid values and the Soft LOV? property on the domain. (Alternatively, you can put both of those items on the column itself.) Certain types of GUI formatting--Radio Groups and Check Boxes--invalidate the use of the Soft LOV? concept due to their very nature.
The Derivation text field allows you to comment on the source of values for the domain. For example, you might want to record that "These customer credit ratings are based on standard Dun and Bradstreet classifications." This property, which is used for documentation only, is passed to attributes and columns in the domain when the update utilities are run.
The Derivation Expression property, when defined on columns, gives you a powerful capability to direct the Generators to produce specific code. However, when defined on a domain, it isn't passed along to either its attributes or its columns. If you know that columns within the domain will be derived with specific code, it's to your advantage to record that fact on the domain. However, because the domain utilities don't pass this property down, you'd need to write your own utility to transfer this information onto attributes and columns.
Each domain can have a list of valid fixed values. That fixed list of values is stored in the Domain Allowable Value field. This field isn't used for domains that will be implemented via a relationship to a reference entity, as the reference entity itself will hold the valid values. A given allowable value can be either a single value or a range of values. The DDL Generator can create a check constraint on columns within the domain to enforce these allowable values at the database level. Select the option Valid Value Constraints when you generate the DDL.
The Value property represents either the low end of an allowable range of values or one allowable discrete value of a list. If you wanted your domain to be a range of values, such as 0 to 100 for the domain Test Score, you'd place the lowest allowable value, 0, in the Value property. If your domain has a list of allowable discrete values, such as Male, Female for the domain Gender, then you'd enter the value Female here, representing a single allowable value for the domain Gender. (When you create a domain with a list of allowable values, you'll create a separate Allowable Values entry for each entry of the list.)
In the example for Value above, you'd leave the High Value field blank for the domain Gender and enter 100 for the domain Test Score.
If the value stored in the above two fields isn't obvious, you can store a short text phrase that describes the value. For example, if you'd chosen to store a value of F in the domain Gender, you might want to store the meaning Female in the Meaning field. Users will see the longer description in generated lists of values.
If you chose to store the value Female in the database for domains of Gender, you might not want your users to have to type the entire phrase Female in your forms. You might allow them to type in the abbreviation F and have the Oracle Forms Generator translate the abbreviation into its proper value.
Display Sequence refers to the order in which allowable values for the domain will be displayed. If you don't specify the display sequence, the values will be displayed in alphabetical order.
You can use the Text property to more fully define the domain. The Generators do not use the text you enter.
There are several reports pertaining to domains. In Table A, we highlight the most useful standard reports that are applicable while you're working on your system's domains.
Table B shows two useful domain utilities. To run any of the utilities, select one or more domains in the Object Hierarchy window of the Repository Object Navigator, then select the appropriate update from the Utilities menu.
TABLE A
This report lists by domain all attributes assigned to that domain. It's also useful for checking attribute-naming consistency within a domain.
Same as above, but for columns in a domain.
This report prints out the details of each selected domain.
Attributes in Domains Across Application Systems
Attributes in Domains Across Application Systems
This report is useful once you have multiple application systems in the Repository. It shows which domains are used by which application system and by which entity. It also shows which application system is the owner of the domain and shows the ownership of the entities using the domain. You can also use this report to check for naming consistency.
TABLE B
This utility updates the datatype, default value, size, and precision fields in each attribute assigned to a domain so that the attribute and domain agree.
This utility updates the datatype, default value, size, and precision fields in each column assigned to a domain so that the column and domain agree.
Domains can provide the Designer/2000 application developer a number of advantages. They can reduce data entry effort, promote consistency of attribute and column definitions across the application, and provide a common point of definition for Generator preferences. They can also save you tremendous time and effort when you need to make changes to attribute or column definitions.
Carrie Anderson works for Oracle Corporation as the CASE Education Manager for Central and West US. This article is extracted from An Introduction to Oracle's Designer/2000, co-authored by David Wendelken and available from Addison-Wesley in mid-1996.
[Return to Index for Exploring Oracle Developer/2000 and Designer/2000 - May 1996]
Copyright (c) 1996 The Cobb Group, a division of Ziff-Davis Publishing Company. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of Ziff-Davis Publishing Company is prohibited. The Cobb Group and The Cobb Group logo are trademarks of Ziff-Davis Publishing Company.
1-800-223-8720
(Sun Microsystems, Inc.)(1997).iso/products/Cobb/ord9605/eod9654a.gif){kind=link}